The present invention relates to a method and to an architectural model for level 1 ISO-OSI protocol intended to handle a pool of hardware resources, that is a common hardware platform comprising circuits all of the same type, with the main purpose to share such pool of hardware resources among different applications making use of them, ensuring easy replaceability of the circuits in use in the event of a hardware fault.
ANSI-IEEE: xe2x80x9cLocal Area Networks, Carrier Sense Multiple Access with collision Detection (CSMA/CD) Access Method and Physical Layer Specificationxe2x80x9d, 1985, The Institute of Electrical and Electronic Engineers, Inc., New York XP 002058470 155440xe2x80x9d describes the functionalities allocated at the ISO-OSI Layer 1 Protocol as consisting of hardware control part, depending on the used physical means, and of a hardware utiliser part making use of such physical means.
However, the above mentioned document only depicts the case where one single application makes use of a number of possible physical means. It does not in any way hint at the case of several applications which makes use, at the same time, of a pool of hardware resources, all of the same type, provided by a common hardware platform.
Different applications, all working at Layer 1, can make indeed a different use of the same hardware, but the hardware as such, being the same, will be supervised and maintained in the same way, independently of what the application is.
For example, the Primary Rate Access of ISDN includes a sectionalised maintenance of the digital link according to ETSI ETS 300 233 rules, while the other types of accesses do not. Some digital links may be used for connecting the subscribers to the exchange, some others to connect exchanges among them; their handling could result in different implementations of the software managing the Layer 1 functions.
The present technology makes it possible to create compact cards hosting several circuits which implement the Layer 1 functions, such as receiver, code transmitters (CSR), Exchange Terminals (ETs), echo suppressors (ES). Therefore, now that several circuits will be hosted on the same card, the need arises to handle a pool of circuits of the same type and with the same characteristics.
Taking into account for sake of example ET circuits, when one card was corresponding to one ET circuit, each software product implementing the Layer 1 functions was controlling its number of ET cards and the concept of common hardware platform was not necessary to be introduced. To have a common supervision and maintenance of the hardware was indeed not so critical.
Presently, since a common part of the software is intended to the Layer 1 applications (the situation in terms of software products may be, for instance, the one depicted in FIG. 1 of the annexed drawings), this part will handle the supervision, testing and maintenance of the hardware.
This results in a few problems, namely:
a) Since there is the need to copy the common software part from one Layer 1 application to another one, the risk arises that a fault in this common part affects several different software products.
b) The same card can be configured in different ways according to the needs, which means that the distribution of the ET circuits among the several Layer 1 applications can differ from a card to another. This might result in some systems to an oversizing of the files existing within single software products, in order to match them to the maximum number of ET circuits to be controlled on the different cards, leading to a waste of memory usage.
c) In case an automatic change of the card is active in the event of fault, the spare card must be exactly configured as the replaced one, forcing all cards sharing the same spare unit (N+1 redundancy) to have the same distribution of ET circuits among the Layer 1 applications.
d) If a global test of the card is ordered by the operator, this function will have to poll all software products implementing the Layer 1 applications, each for its quote of controlled ET circuits.
e) To introduce a new Layer 1 application involves the repetition of the part of common software, directly managing the hardware. Presently no solution to the above mentioned problems is available, also because the possibility to host several circuits having the same function on the same card has been made available by the technology only recently.
The present invention is involved with such problems and satisfactorily solves them by providing a method and an architectural model intended to handle a pool of hardware resources.
According to the invention, a method for handling a pool of hardware resources within an architectural model for level 1 ISO-OSI protocol, of the type comprising two sublayers, the lowest of them (PHLR) being designed to the control functions of a common hardware platform and the highest (PHLU) being designed to the functions of the use of the hardware resources, wherein the lowest sublayer (PHLR) does not know which is the use of the hardware resources and the highest sublayer (PHLU) does not know implementing features of hardware resources and wherein the lowest sublayer (PHLR) communicates with the highest sublayer (PHLU) to provide information about the status of the hardware in use, is characterised in that, it utilizes said information to make possible the replacement of a used circuit in the event of a fault.
The invention furthermore concerns an architectural model for level 1 ISO-OSI protocol of the type described above, which allows the allocation of physical hardware circuits to the various applications using resources provided by the common hardware platform in a flexible way.